前言

我們都知道 Grafana 的強大功能，而將這些配置為程式碼可以進一步提升我們開發維護的效率。如今，Grafana 的大多數資源都可以透過聲明性方式作為程式碼進行管理，這樣做不僅能實現程式碼審查和重用，還能優化整體工作流程。

在這個章節中，我們將依據 2022 年 Grafana 官方文章 《A Complete Guide to Managing Grafana as Code: Tools, Tips, and Tricks》 的脈絡，介紹一些可用於聲明性管理 Grafana 資源的程式碼工具。基於這些工具的現狀和我個人的觀察，我也將提供相應的見解。

TL;DR

在這裡我提前先為各位下了自己的總結：

• Grafana Terraform Provider：成熟並且支援最多 Grafana 資源，包含 OSS 和 Cloud 版本。
• Grafana Ansible Collection：僅支援部分 Grafana 資源，多需要自己串 Grafana API，且與社群版本合併之路不順。
• Grafana Operator：對 Kubernetes 使用者相當友好，如果僅需要 Grafana Instance、Dashboard、Folder、User 等基本功能，非常推薦。
• Grafana Crossplane provider：相容程度與 Grafana Terraform Provider 相當，但僅適合有使用 Crossplane 的團隊，否則將會帶來額外學習成本。

最後我個人的選擇是：Terraform、Jsonnet 。其原因不外乎是 Terraform 的支援度，同時 Terraform 也是較多人熟悉的工具，而 Jsonnet 則是 Grafana 全力支持的 Json 設定檔管理最佳方案，我們將會在後面的章節稍做介紹。

Grafana Terraform Provider

Grafana Terraform Provider 是目前最完整的 Grafana 資源管理工具之一，支援 Grafana Cloud、Grafana Enterprise 以及 Grafana OSS 三種版本。該提供者保持快速且穩定的更新頻率，這使得它成為管理 Grafana 資源的最佳選擇之一。

最大的優勢在於它的資源支持廣泛，幾乎覆蓋了所有你在 Grafana 中會使用到的配置項目。通過 Terraform，您可以將這些配置納入基礎設施即代碼（IaC）流程中，實現自動化和版本控制，極大提高了配置管理的可預測性和可靠性。

有鑑於 Terraform 在如今的 DevOps 領域已經極其成熟廣泛，使用 Grafana Terraform Provider 作為對基礎架構的擴充方案，除了可以快速融入團隊框架並且可以省去維護人員的學習成本，並且防止使用技術過於發散。

Support Resources：

• Grafana Cloud
• Grafana Enterprise
• Grafana OSS
• Alerting
• OnCall
• SLO
• Machone Learning
• Synthetic Monitoring

Grafana Ansible Collection

Grafana Ansible Collection 是另一個有潛力的工具，它將 Grafana 的建置與 Ansible 結合，使得我們可以使用 Ansible Playbooks 來管理 Grafana 的 Alert 和 Dashboard 等基本設定。然而，該工具目前對於 Grafana 資源的支援仍然有限，僅涵蓋了少數幾個基本項目。此外，該 Collection 與社群版本仍然並行存在，尚未完全整合，這使得在使用時可能需要面對版本兼容性和功能不一致的問題。

這個工具的主要優勢在於它與 Ansible 生態系統的緊密整合與 Terraform 的定位相去不遠，允許我們使用已經熟悉的工具和流程來管理 Grafana，而不需要學習新的語法或工具。

Support：

• Grafana Ansible Collection
  • alert_contact_point
  • alert_notification_policy
  • cloud_api_key
  • cloud_plugin
  • cloud_slack
  • dashboard
  • datasource
  • folder
• Community.Grafana Ansible Collection
  • annotations
  • dashboard
  • datasource
  • folder
  • notification_channel
  • contact_point
  • organization
  • organization_user
  • plugin
  • team
  • user
  • silence

Grafana Ansible Collection 與 Community.Grafana COllection 的合併現況

我們可以注意到，在 2022 年時，官方的 Grafana Ansible Collection 與社群維護的 community.grafana Ansible Collection 幾乎已達成合併，只差一步點擊 PR merge。然而，這一合併卻因為 Grafana 轉為 GPL-3.0 許可證時同時導入的 CLA 協議而戛然而止。CLA 協議雖然是一種保障貢獻者與開源項目之間的法律協議，但其中規定貢獻者需確保其提交的內容不侵犯第三方的知識產權，並將著作權和專利授權授予擁有該軟體智慧財產權的公司或組織。如果內容侵犯他人權利，責任將歸屬於貢獻者。這樣的規定聽起來或許有些不可思議，但實際上，許多組織都是這麼做的，例如 Mozilla 曾花費數年時間（2001-2006 年）重新為 Firefox、Thunderbird 及相關軟體進行授權。儘管這些措施出於善意，但對於某些自由開源開發者來說，簽署這樣一份將責任歸咎於自己的協議，尤其是面對一個擁有商業產品的開源供應商時，難免會有些心理上的疙瘩。

Grafana Operator

Grafana Operator 是 Kubernetes 環境下的一個強大工具，通過自訂資源（Custom Resource, CR）來設定、管理和操作 Grafana 的實例及其相關資源。這個工具將 Grafana 的管理完全容器化和自動化，使我們能夠利用 Kubernetes 的經驗來高效管理、監控和擴展 Grafana 的資源。

Grafana Operator 特別適合已經在使用 Kubernetes 的團隊，因為它能無縫集成到 Kubernetes 的管理和部署管道中，並提供聲明式的方法來管理 Dashsource、Dashboard 和 Folder。它還自動同步 Kubernetes 自訂資源與 Grafana 實例中的實際資源，並支援利用 Grafonnet 以程式碼形式生成和配置 Grafana 儀表板，從而簡化了整個管理流程，提升了自動化操作的效率。

Support：

• Grafana Instance
• Dashboards
• Datasources
• Alerting (2024/3 partial)

Grafana Operator 與上游官方庫合併

在 2023 年底時，原位於 Intergr8ly 組織下的 Grafana Operator 團隊興奮的宣布他們將把這個專案合併到上游的 Grafana 組織中，畢竟自己利用業餘時間開發出來的 side project 被納入官方庫，這對所有開源專案開發者某種程度是極大的認可。這次合併的目的是讓 Operator 獲得更多的認可，進一步擴大其社群影響力和吸引力。值得注意的是，這個專案的維護者們目前大多數是利用業餘時間來維護該專案，這也導致了開發進度相對緩慢，一些功能需求長時間未能得到實現。通過這次合併，團隊希望吸引更多的開發者參與，加快專案的開發進程。

ref:

• https://grafana.github.io/grafana-operator/blog/2023/11/21/moving-upstream/

來自 Grafana Labs 的助力

長期以來，Grafana Operator 社群一直期望能夠新增與 Alerting 相關的設定資源，以解決 Grafana Alerting 難以進行版本控制和維護的問題。終於在今年年初，Grafana 官方人員對長期懸而未決的一兩年內的 Alerting 計畫進行了拍板定案，並實作出了初步版本的 Grafana Alerting Rule CRD（Custom Resource Definition），使該專案開始有了明確的方向和新的生機。

ref:

• https://github.com/grafana/grafana-operator/pull/1420
• https://github.com/grafana/grafana-operator/pull/1144
• https://github.com/grafana/grafana-operator/issues/911

Grafana Crossplane provider

Grafana Crossplane Provider 是 Crossplane 生態系統中的一部分，並且他是使用 Terrajet 從 Grafana Terraform Provider 轉換而成的，這代表他能夠提供 Grafana Terraform Provide 所有支援的 Grafana 資源，這是 Crossplane 的其中一項特點。此外，Crossplane 允許我們使用 Kubernetes 的 API 來管理 Grafana 資源。通過 Grafana Crossplane Provider，我們可以將 Grafana 的設定以 Kubernetes CRD 風格來進行管理，這在高度依賴 Kubernetes 進行基礎設施管理的環境中特別有用。

這個工具的優勢在於它的 Kubernetes 原生支持，允許我們利用 Kubernetes 的強大管理功能來處理 Grafana 的資源和配置，實現高度自動化和可擴展的解決方案。然而，這取決於團隊是否已經在使用 Crossplane 作為基礎設施管理工具。畢竟，Grafana as Code 只是 Infra as Code 實踐的一部分，如果團隊已經在使用其他 IaC 技術，導入 Crossplane 可能會增加團隊的負擔，因此需要仔細考慮其適用性。

Crossplane 與 Terraform Provider 的整合

• Terraform Provider 兼容性：
  • Crossplane 可以透過一種名為 Terrajet 的工具生成 Provider 的程式碼，這些程式碼能與現有的 Terraform Provider 進行整合。因此，Crossplane 可以利用 Terraform Provider 來管理基礎設施資源。
  • Terrajet 是一種工具鏈，它會自動生成基於 Crossplane 的 Provider 程式碼，這些程式碼依賴於 Terraform Provider，並透過調用這些 Provider 來管理資源。這意味著 Crossplane 在一定程度上可以兼容並使用 Terraform Provider。
• Crossplane 的工作原理：
  • Crossplane 是一個 Kubernetes 原生的控制平面，透過 Kubernetes 的 CRD 和控制器來管理資源。Crossplane 的目標是將基礎設施管理與 Kubernetes 的 API 統一起來，使基礎設施資源能像 Kubernetes 資源一樣被聲明和管理。
  • 當 Crossplane 需要管理某個資源時，它可以透過一個專門的 Provider（包括 Terraform Provider）來實現這個目標，但它並不直接使用 Terraform 的二進位檔案或狀態管理方式。

結論

將 Grafana 配置管理為程式碼，提供了更高的靈活性與可控性，使我們能更有效地管理和維護 Grafana 環境。無論你是透過 Terraform 進行全面的資源管理，還是利用 Ansible 和 Grafana Operator 在現有基礎設施中實現自動化，這些工具都能顯著提升你的工作流程。通過這些工具，我們能更充分地發揮 Grafana 的強大功能，確保在各種環境中都能保持一致且可靠的配置管理。

還記得我們先前強調的 Grafana 設定檔管理、文化建立以及方法論嗎？這些要素都是建構穩定且高效的 Grafana 環境的關鍵，而導入 Infra as Code 工具便是實現這些目標的重要方式之一。透過 IaC 工具，我們不僅可以建立設定檔管理的架構和規範，還能培養使用者養成使用 IaC 工具及版本控制的良好習慣，並充分運用官方提供的各種優化功能。這種多管齊下的方法，將使我們更接近打造一個「好」的 Grafana 架構。

References:

• https://github.com/monitoring-mixins/mixtool
• https://grafana.com/blog/2020/02/26/how-to-configure-grafana-as-code/?pg=blog&plcmt=body-txt
• https://grafana.com/blog/2022/06/06/grafana-dashboards-a-complete-guide-to-all-the-different-types-you-can-build/?pg=webinar-getting-started-with-grafana-dashboard-design-amer&plcmt=related-content-1
• https://grafana.com/docs/grafana/latest/administration/provisioning/